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Commissioner for Patents: 

This appellant's brief is being filed under 37 CFR 41.37 (effective date of 
September 13, 2004) in response to a Notice of Panel Decision from Pre-Appeal Brief Review 
mailed on April 9, 2010, which set an extendible deadline of one-month from the mailing of the 
panel decision (i.e., a deadline of May 9, 2010) to file the present appellant's brief. The present 
appellant's brief is being filed by said deadline in furtherance of the Notice of Appeal, filed in this 
case on November 5, 2009. 

The fees required under Section 1.17(c), and any required request for extension of 
time for filing this appellant's brief and fees therefor, are dealt with in the accompanying papers. 
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I. REAL PARTY IN INTEREST 

Foundry Networks, Inc. is the real party in interest. On December 19, 2008, 
Brocade Communications Systems, Inc. acquired Foundry Networks, Inc. Foundry Networks, 
Inc. is now a wholly-owned subsidiary of Brocade Communications Systems, Inc. Subsequently, 
Foundry Networks, Inc.'s name/form was changed to Foundry Networks LLC, but it remains a 
wholly-owned subsidiary of Brocade Communications Systems, Inc. 

II. RELATED APPEALS AND INTERFERENCES 

None 

III. STATUS OF CLAIMS 

Claims 1-36 and 43-52 are pending and have been at least twice rejected. The 
rejection of claims 1-36 and 43-52 is being appealed herein. Claims 37-42 have been previously 
canceled. 

IV. STATUS OF AMENDMENTS 

There are no outstanding amendments. The last amendment/response was filed on 
March 5, 2008. A final Office Action was mailed on June 12, 2008 that finally rejected claims 1- 

36 and 43-52. An appeal was filed to request withdrawal of the rejections set forth in the final 
Office Action of June 12, 2008, and in response to filing said appeal, the Examiner reopened 
prosecution by mailing an Office Action on August 5, 2009 (hereinafter referred to as "the Office 
Action of August 5, 2009"). The present appellant's brief is being filed to address the rejections 
set forth in the Office Action of August 5, 2009. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The claimed subject matter in the present U.S. Patent Application Serial No. 
10/756,152 (hereinafter referred to as "the present application") is directed towards a method, 
apparatus, and article of manufacture to maintain/extend persistency of a connection. 

The following discusses independent claims 1, 14, 22, and 31. According to 

37 CFR 41.67(c)(l)(v), a concise explanation of the subject matter in the independent claims has 
been set forth below with reference to the specification by page and line numbers, and to the 
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drawings, if any, by reference characters. Accordingly, the following shows claims 1, 14, 22, and 
3 1 together with the required reference information in brackets [ ] and italicized. Of course, the 
reference numbers and other bracketed information are illustrative only and are not intended to 
limit the claims only to the exact embodiments shown and described in the specification and 
figures of the present application. 

1 . A method, comprising: 

at a network device [page 7, lines 17-18; 108 in Figure 1 and Figures 3-4; page 7, 
lines 8-20], providing a hypertext transfer protocol (HTTP) client-side connection and a HTTP 
server-side connection [page 8, lines 4-17; client-side connection line between client 102 and 
switch/gateway 108 in Figures 3-4; and server-side connection line 304/402 between 
switch/gateway 108 and server 114 in Figures 3-4]; 

receiving at said network device via said client-side connection a communication 
that signals said server-side connection to close [Request 1 at 202 in Figure 2; Request 1 at 300 in 
Figure 3; Request 1 at 400 in Figure 4; page 9, lines 22-26; page 10, lines 3-5; and page 12, 
lines 5-9]; and 

maintaining persistent, by said network device, at least the server-side connection 
in response to said communication received via said client-side connection [page 5, lines 6-7; 
Request 1 ' in Figure 3; Request 1 ' at 404 in Figure 4; page 8, lines 18-28; page 9, lines 1-7; 
page 10, lines 3-16; page 11, lines 5-10; page 11, line 16 to page 12, line 3; and page 12, lines 
4-14]. 

14. A method, comprising: 

establishing at a network device [page 7, lines 17-18; 108 in Figure 1 and Figures 
3-4; page 7, lines 8-20] a client-side connection and a server-side connection [page 8, lines 4-1 7; 
client-side connection line between client 102 and switch/gateway 108 in Figures 3-4; and server- 
side connection line 304/402 between switch/gateway 108 and server 114 in Figures 3-4]; 

reading, by said network device, content of a packet received via the client-side 
connection [Request 1 at 202 in Figure 2; Request 1 at 300 in Figure 3; Request 1 at 400 in 
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Figure 4; page 9, lines 22-26; page 10, lines 3-5; page 12, lines 5-9; and page 16, lines 9-11]; 
and 

extending, by said network device, persistency of the server-side connection if the 
read content of the packet signals said server-side connection to close [page 5, lines 6-7; Request 
1 ' in Figures 3-4; page 8, lines 18-28; page 9, lines 1-7; page 10, lines 3-16; page 11, lines 5-10; 
page 11, line 16 to page 12, line 3; and page 12, lines 4-14]. 

22. An article of manufacture, comprising: 

a storage medium having instructions stored thereon [112 in Figure 1; page 7, 
lines 11-13] that are executable by a processor [110 in Figure 1; page 7, lines 13-15] of a network 
device [page 7, lines 17-18; 108 in Figure 1 and Figures 3-4; page 7, lines 8-20] to: 

provide at said network device a hypertext transfer protocol (HTTP) client-side 
connection and a HTTP server-side connection [page 8, lines 4-17; client-side connection line 
between client 102 and switch/gateway 108 in Figures 3-4; and server-side connection line 
304/402 between switch/gateway 108 and server 114 in Figures 3-4]; 

receive via said client-side connection a communication that signals said server- 
side connection to close [Request 1 at 202 in Figure 2; Request 1 at 300 in Figure 3; Request 1 at 
400 in Figure 4; page 9, lines 22-26; page 10, lines 3-5; and page 12, lines 5-9]; and 

maintain persistent, by said network device, at least the server-side connection in 
response to said communication received via said client-side connection [page 5, lines 6-7; 
Request 1 ' in Figure 3; Request 1 ' at 404 in Figure 4; page 8, lines 18-28; page 9, lines 1-7; 
page 10, lines 3-16; page 11, lines 5-10; page 11, line 16 to page 12, line 3; and page 12, lines 
4-14]. 

31. An apparatus, comprising: 

a network device [page 7, lines 17-18; 108 in Figure I and Figures 3-4; page 7, 
lines 8-20] having: 

first and second communication terminals [Figures 1 and 3-4: terminal of 
the switch/ gateway 108 coupled to the client 102 and terminal of the switch/gateway 108 
coupled to the server 114; page 20, line 11], the first terminal being associated with a 
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hypertext transfer protocol (HTTP) client-side connection and the second terminal being 
associated with a HTTP server-side connection {page 8, lines 4-1 7; client-side connection 
line between client 102 and switch/gateway 108 in Figures 3-4; and server-side 
connection line 304/402 between switch/gateway 108 and server 114 in Figures 3-4]; 

a processor coupled to the first and second communication terminals [110 
in Figure 1; page 7, lines 13-15; page 20, line 15]; and 

software executable by the processor [112 in Figure 1; page 7, lines 11-15] to 
maintain persistent [page 5, lines 6-7; Request 1 ' in Figure 3; Request 1 ' at 404 in Figure 4; page 
8, lines 18-28; page 9, lines 1-7; page 10, lines 3-16; page 11, lines 5-10; page 11, line 16 to 
page 12, line 3; and page 12, lines 4-14] at least the server-side connection in response to a 
communication received via said client-side connection that signals said server-side connection to 
close [Request 1 at 202 in Figure 2; Request 1 at 300 in Figure 3; Request 1 at 400 in Figure 4; 
page 9, lines 22-26; page 10, lines 3-5; and page 12, lines 5-9]. 

The following claims 27-30 and 49-51 contain means-plus-function elements 
falling under the scope of 35 U.S.C. § 112, sixth paragraph. Accordingly, reference information 
in brackets [ ] and italicized is shown in the text of claims 27-30 and 49-51 below, so as to 
comply with 37 CFR 41.37(c)(l)(v) which requires "For each independent claim involved in the 
appeal and for each dependent claim argued separately under the provisions of paragraph 
(c)(l)(vii) of this section, every means plus function and step plus function as permitted by 35 
U.S.C. 1 12, sixth paragraph, must be identified and the structure, material, or acts described in the 
specification as corresponding to each claimed function must be set forth with reference to the 
specification by page and line number, and to the drawing, if any, by reference characters." 
Again, the reference numbers and other bracketed information are illustrative only and are not 
intended to limit claims 27-30 and 49-51 to only the exact embodiments shown and described in 
the specification and figures of the present application. 

27. An apparatus, comprising: 

a network device [page 7, lines 17-18; 108 in Figure 1 and Figures 3-4; page 7, 
lines 8-25] adapted to be communicatively coupled between a client terminal [102 in Figures 1-4; 
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page 7, lines 1-3] and a server [114 in Figures 1-4; page 7, lines 21-25], the network device 
having: 

communication terminal means for establishing a client-side connection 
and a server-side connection [Figures 1 and 3-4: terminal of the switch/gateway 108 
coupled to the client 102 and terminal of the switch/gateway 108 coupled to the server 
114; client-side connection line between client 102 and switch/gateway 108 in Figures 3- 
4; and server-side connection line 304/402 between switch/gateway 108 and server 114 in 
Figures 3-4; page 20, line 11; page 8, lines 4-17]; and 

means for reading content of a packet received via the client-side 
connection, and for extending persistency [110 and 112 in Figure 1; page 7, lines 11-15; 
page 5, lines 6-7; Request 1 ' in Figure 3; Request 1 ' at 404 in Figure 4; page 8, lines 18- 
28; page 9, lines 1-7; page 10, lines 3-16; page 11, lines 5-10; page 11, line 16 to page 
12, line 3; and page 12, lines 4-14] of the server-side connection if the read content of the 
packet signals said server-side connection to close [Request 1 at 202 in Figure 2; Request 
1 at 300 in Figure 3; Request 1 at 400 in Figure 4; page 9, lines 22-26; page 10, lines 3- 
5; and page 12, lines 5-9]. 

28. The apparatus of claim 27 wherein the means for extending the persistency 
of the server-side connection modifies header information in the packet to a format 
unrecognizable [ "Connection: Cselo " in Request 1 ' in Figure 3; page 11, line 16 to page 12, line 
3] to a server coupled to said server-side connection to receive said packet . 

29. The apparatus of claim 27 wherein the means for extending the persistency 
of the server-side connection modifies header information in the packet to indicate a protocol 
version that corresponds to a persistent connection ["HTTP/1.1 " in Request 1 ' in Figure 4; page 
12, lines 4-14]. 

30. The apparatus of claim 27 wherein the means for extending the persistency 
of the server-side connection de-links the server-side connection from the client-side connection 
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in response to RESET content in the packet received via the client side connection [page 8, lines 
18-28]. 

49. The apparatus of claim 27 wherein the means for extending the persistency 
of the server-side connection, if the read content of the packet signals said server-side connection 
to close, maintains persistency by de-linking the server-side connection from the client-side 
connection in response to FIN content in the packet received via the client side connection {page 
9, lines 1-11]. 

50. The apparatus of claim 27 wherein the means for extending the persistency 
of the server-side connection, if the read content of the packet signals said server-side connection 
to close, maintains persistency by de-linking the server-side connection from the client-side 
connection in response to RESET content in the packet received via the client side connection 
[page 8, lines 18-28]. 

5 1 . The apparatus of claim 27 wherein the means for extending the persistency 
of the server-side connection, if the read content of the packet signals said server-side connection 
to close, maintains persistency by replacing a Connection: Close header of the packet with a 
Connection: Keep-Alive header [Request 1 at 300 in Figure 3; page 10, line 3 to page 11, line 4\ 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 1-5, 9-34, 36, 43-50, and 52 are unpatentable under 35 U.S.C. 

§ 103(a) over Craig (U.S. Patent No. 7,031,314) in view of Peiffer (U.S. Patent No. 7,055,028). 

Whether claims 6-8, 35, and 51 are unpatentable under 35 U.S.C. § 103(a) over 

Craig in view of Peiffer, and further in view of Susai (U.S. Patent No. 6,954,780). 
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VII. ARGUMENT 



A. Requirements for nonobviousness under Section 103 

Consistent with a long line of judicial holdings, MPEP § 2143.03 states that "All 
words in a claim must be considered in judging the patentability of that claim against the prior art. 
In re Wilson, 424 F.2d 1382, 1385, 165 USPQ 494, 496 (CCPA 1970)." In order to find prima 
facie obviousness when combining references, MPEP § 2143(A)(1) states the following 
(emphasis ours): "Office personnel must articulate the following: (1 ) a finding that the prior art 
included each element claimed , although not necessarily in a single prior art reference, with the 
only difference between the claimed invention and the prior art being the lack of actual 
combination of the elements in a single prior art reference." MPEP § 706.02(j) further states 
(emphasis ours): "To support the conclusion that the claimed invention is directed to obvious 
subject matter, either the references must expressly or impliedly suggest the claimed invention or 
the examiner must present a convincing line of reasoning as to why the artisan would have found 
the claimed invention to have been obvious in light of the teachings of the references. Ex parte 
Clapp, 227 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985)." 

The rejections of claims 1-36 and 43-52 do not meet these requirements for a 
rejection based on obviousness, since the cited references (whether singly or in combination) do 
not teach or suggest all of the claim limitations. 

B. Independent claim 1 should not be rejected under 35 U.S.C. § 103(a) on the 
basis of Craig and Peiffer 

Independent claim 1 recites, inter alia, the following limitations (emphasis ours): 

"receiving at said network device via said client-side connection a 
communication that signals said server-side connection to close, and 

maintaining persistent, by said network device, at least the 
server-side connection in response to said communication received via 
said client- side connection." 

On page 3 (section 6) of the Office Action of August 5, 2009, the Examiner cites 
column 17, line 57 to column 18, line 1 1 of Craig as allegedly teaching "receiving at the network 
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device via the client-side connection a communication that signals the server-side connection to 
close" (emphasis ours). The Examiner further asserts on page 3 (section 6) of the Office Action 
of August 5, 2009 that this passage of Craig teaches that "during the close state the service 
module responds to communication received by the client in order to close connection that 
closing [sic] the client-side connection and maintaining the server-side connection" (emphasis 
ours). 

The Examiner's assertions that Craig teaches the recitations of claim 1 are 
traversed herein. Craig's column 17, line 57 to column 18, line 1 1 relied upon by the Examiner is 
reproduced below (emphasis ours): 

"After the transaction state is complete, the communication session 
may then enter into an update state (as indicated generally at 440) that 
closes the communication session and a close state (as indicated generally 
at 450) that closes the connection between the wireless client 110 and the 
server 180. . During the close state, however, the operating system and 
networking stack of the service module 190 responds to messages 
received by the wireless client 110 in order to close the client-side 
connection. The operating system and networking stack then notifies the 
service application that the client-side connection has been closed, and the 
service application responds by initiating closure of the server-side 
connection. The operating system and networking stack of the service 
module 190 then engages in conventional closure handshakes with the 
server 180 in order to close the server-side connection as indicated 
generally at 455." 



Thus, Craig clearly teaches above that he closes (rather than "maintaining 
persistent") his server-side connection in response to a communication {e.g., Craig's 
above-described "conventional closure handshakes" and/or "...responds to messages received by 
the wireless client 110") that signals the server-side connection to close. Accordingly, Craig does 
not meet the limitations of claim 1 that require, inter alia, "receiving at said network device via 
said client-side connection a communication that signals said server-side connection to close; 
and maintaining persistent, by said network device, at least the server-side connection in 
response to said communication received via said client-side connection" (emphasis ours). 

On page 4 (section 6) of the Office Action of August 5, 2009, the Examiner relies 
upon Peiffer (column 9, line 58 to column 10) as allegedly teaching "maintaining persistent... at 
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least the server-side connection in response to..." However, column 9, lines 62-63 of Peiffer 
explicitly teaches that the persistent connection is maintained open "unless explicitly commanded 
to close" (emphasis ours). Therefore, Peiffer will also CLOSE (rather than "maintaining 
persistent" as recited in claim 1) the server-side connection in response to a communication that 
signals ("explicitly command[s]") the server-side connection to close. Thus, Peiffer does not cure 
the deficiencies of Craig with respect to the recitations in claim 1 of "receiving at said network 
device via said client-side connection a communication that signals said server-side connection to 
close; and maintaining persistent, by said network device, at least the server-side connection in 
response to said communication received via said client-side connection." 

In view of the above, since all of the limitations of claim 1 are not met by the cited 
references, claim 1 is not obvious. 

C. Dependent claims 2-5, 13, and 43 should not be rejected under 35 U.S.C. 
S 1 03(a) on the basis of Craia and Peiffer 

Dependent claims 2-5, 13, and 43 depend on claim 1, and by virtue of this 
dependency, are nonobvious over the cited references for the reasons set forth above with respect 
to claim 1 . 

D. D ependent claims 6-8 should not be rejected under 35 U.S.C. § 103(a) on 
the basis of Craig, Peiffer, and Sakai 

Dependent claims 6-8 depend on claim 1, and by virtue of this dependency, are 
nonobvious over the cited references for the reasons set forth above with respect to claim 1 . 

E. Dependent claims 9-10 should not be rejected under 35 U.S.C. § 103(a) 
on the basis of Craig and Peiffer 

Dependent claim 9 depends on claim 1, and by virtue of this dependency, is 
nonobvious over the cited references for the reasons set forth above with respect to claim 1 . 

Dependent claim 9 is also nonobvious due to the limitations recited therein. In 
particular, dependent claim 9 recites, inter alia, the following limitations (emphasis ours): 



10 



"wherein maintaining persistent at least the server-side 
connection in response to said communication received via said client- 
side connection includes: 

modifying, by said network device, a header in the 
communication from a format that signals the server-side connection to 
close to a format that is unrecognizable by a server coupled to said 
server-side connection, to cause the server to ignore the modified header." 



These limitations are not met by the cited references. Page 6 (section 10) of the 
Office Action of August 5, 2009 cites the following passages of Craig as allegedly teaching the 
recitations of claims 9-10: Figure 3A; column 11, line 45 to column 12, line 3; column 8, lines 1- 
12; and column 11, lines 1 1-44. However, the reliance upon Craig by the Examiner to support the 
rejection is in error. 

Column 8, lines 1-12 and column 11, lines 11-44 of Craig disclose the following 
(emphasis ours): 

"...a set of classification rules that mask one or more fields of the packet 
header, such as the source address, destination address, source port, 
destination port, protocol field and device ID, to determine whether the 
combination of fields match a predetermine value or range of 
predetermined values specified by the classification rule. If a connection 
between the wireless client 1 10 and the server 180 matches a classification 
rule, the service module 190 breaks the connection between the wireless 
client 110 and the server 180 by terminating the connection with the 
wireless client 110 at the service module 190 and opening a separate 
connection between the service module 190 and the server 180." 



Thus, assuming arguendo and hypothetically that Craig's "mask" can be 
interpreted as the "format that is unrecognizable" recited in claim 9, Craig still does not meet the 
other recitations of claim 9 that require "maintaining persistent at least the server-side 
connection." As clearly set forth above by Craig in the passage above, his mask (if there is a 
match of the classification rule) results in "opening a separate connection between the service 
module 190 and the server 180." Therefore, the persistency of the server-side connection is not 
being maintained by Craig through the use of the masked header, but rather he opens a new 
separate connection. 
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Still further, claim 9 recites "...to cause the server to ignore the modified header" 
(emphasis ours). Craig does not ignore the header that has masked values. Rather than ignoring, 
Craig explicitly states that he "determine[s] whether the combination of fields match a 
predetermine [d] value or range of predetermined values specified by the classification rule." By 
having to determine whether the combination of fields in the header matches the classification 
rule, Craig explicitly/implicitly does not ignore the header. 

The other passages of Craig relied upon by the Examiner (Figure 3A and column 
11, line 45 to column 12, line 3) discuss modification of a packet header if the packet matches a 
classification rule, and is silent with respect to the "format that is unrecognizable" and "ignore" 
recitations of claim 9. 

In view of at least the reasons above that the cited references do not meet all of the 
limitations of claim 9, claim 9 is not obvious. 

Dependent claim 10 depends on claim 9, and by virtue of this dependency, is also 
nonobvious over the cited references for the reasons set forth above. 

F. Dependent claims 11-12 and 44 should not be rejected under 35 U.S.C. 

$ 103(a) on the basis of Craig and Pciffcr 

Dependent claim 11 depends on claim 1, and by virtue of this dependency, is 
nonobvious over the cited references for the reasons set forth above with respect to claim 1 . 

Dependent claim 1 1 is also nonobvious due to the limitations recited therein. In 
particular, dependent claim 1 1 recites, inter alia, the following limitations (emphasis ours): 

"wherein maintaining persistent at least the server-side 
connection in response to said communication received via said client- 
side connection includes. 

changing, by said network device, a HTTP version value 
indicated in the communication to another HTTP version value that is 
recognizable by a server, coupled to said server-side connection, as being 
associated with a persistent connection." 

These limitations are not met by the cited references. Page 6 (section 11) of the 
Office Action of August 5, 2009 cites column 9, lines 22-57 of Peiffer. However, this passage of 
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Peiffer is completely silent with respect to "changing... a HTTP version value indicated in the 
communication to another HTTP version value that is recognizable. . .as being associated with a 
persistent connection" (emphasis ours). 

Column 9, lines 47-48 of Peiffer relied upon by the Examiner talks about a ". . .set 
of sockets could be designated for all HTTP 1 .0 requests, with another set being designated to 
handle HTTP 1.1 requests." However, this passage is merely speaking of which type of HTTP 
requests should be designated for a particular set of sockets, and mentions nothing about 
"changing... a HTTP version value indicated in the communication" to "another HTTP version 
value." 

Indeed, even the Examiner states on page 6 (section 11) of the Office Action of 
August 5, 2009 that Peiffer teaches "matching the HTTP request version with server-side socket." 
Again, such interpretation of Peiffer has nothing to do with "changing... a HTTP version value 
indicated in the communication" to "another HTTP version value" as recited in claim 1 1 . 

In view of at least the reasons above that the cited references do not meet all of the 
limitations of claim 11, claim 1 1 is not obvious. 

Dependent claims 12 and 44 depend on claim 11, and by virtue of this dependency, 
are nonobvious over the cited references for the reasons set forth above with respect to claim 1 1 . 

G. Independent claim 14 should not be rejected under 35 U.S.C. § 103(a) on 
the basis of Craig and Peiffer 

Independent claim 14 recites, inter alia, the following limitations (emphasis ours): 

"extending, by said network device, persistency of the server-side 
connection if the read content of the packet signals said server-side 
connection to close." 

In rejecting claim 14 on page 7 (section 15) of the Office Action of August 5, 
2009, the Examiner uses "the same reason" to reject claim 1, in which column 17, line 57 to 
column 18, line 1 1 of Craig was cited as allegedly teaching "receiving at the network device via 
said client-side connection a communication that signals said server-side connection to close." 
As further reason(s), the Examiner asserts on page 3 (section 6) of the Office Action of August 5, 
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2009 that this passage of Craig teaches that "during the close state the service module responds to 
communication received by the client in order to close connection that closing [sic] the client-side 
connection and maintaining the server-side connection." 

The Examiner's assertions that Craig teaches the recitations of claim 14 are 
traversed herein. Craig's column 17, line 57 to column 18, line 11 relied upon by the Examiner 
was previously reproduced above. In this passage, Craig clearly teaches that he closes (rather 
than "extending... persistency of) his server-side connection in response to the "conventional 
closure handshakes" and/or "...responds to messages received by the wireless client 110" that 
signals the server-side connection to close. Accordingly, Craig does not meet the limitations of 
claim 14 that require, inter alia, "extending, by said network device, persistency of the server- 
side connection if the read content of the packet signals said server-side connection to close" 
(emphasis ours). 

On page 4 (section 6) of the Office Action of August 5, 2009, the Examiner relies 
upon Peiffer (column 9, line 58 to column 10) as allegedly teaching "maintaining persistent... at 
least the server-side connection in response to..." However, column 9, lines 62-63 of Peiffer 
explicitly teaches that the persistent connection is maintained open "unless explicitly commanded 
to close" (emphasis ours). Therefore, Peiffer will also CLOSE (rather than 
"extending... persistency of as recited in claim 14) the server-side connection in response to 
"explicitly command[s]" for the server-side connection to close. Thus, Peiffer does not cure the 
deficiencies of Craig with respect to the recitations in claim 14 of "extending, by said network 
device, persistency of the server-side connection if the read content of the packet signals said 
server-side connection to close." 

In view of the above, since all of the limitations of claim 14 are not met by the 
cited references, claim 14 is not obvious. 

H. Dependent claims 15-19 and 45 should not be rejected under 35 U.S.C. 
§ 103(a) on the basis of Craig and Peiffer 

Dependent claims 15-19 and 45 depend on claim 14, and by virtue of this 
dependency, are nonobvious over the cited references for the reasons set forth above with respect 
to claim 14. 
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I. Dependent claim 20 should not be rejected under 35 U.S.C. § 103(a) on 

the basis of Craig and Peiffer 

Dependent claim 20 depends on claim 14, and by virtue of this dependency, is 
nonobvious over the cited references for the reasons set forth above with respect to claim 14. 

Dependent claim 20 is also nonobvious due to the limitations recited therein. In 
particular, dependent claim 20 recites, inter alia, the following limitations (emphasis ours): 

"wherein extending, by said network device, the persistency of the 
server-side connection includes: 

modifying, by said network device, header information in the 
packet received via the client-side connection from a format that signals 
said server-side connection to close to a format that is unrecognizable by 
a server that is to receive the packet via the server-side connection." 

These limitations are not met by the cited references. In rejecting claim 20, page 7 
(section 15) of the Office Action of August 5, 2009 relies upon "the same reason" set forth to 
reject claim 9, in which the following passages of Craig were cited to support the rejection: Figure 
3A; column 11, line 45 to column 12, line 3; column 8, lines 1-12; and column 11, lines 11-44. 
The Examiner's reliance upon Craig to reject claim 20 is erroneous. 

Column 8, lines 1-12 and column 11, lines 11-44 of Craig, which talks about a 
"mask" and classification rules, was previously quoted above. Assuming arguendo and 
hypothetically that Craig's "mask" can be interpreted as the "format that is unrecognizable" 
recited in claim 20, Craig still does not meet the other recitations of claim 20 that require 
"extending... the persistency of the server-side connection." As clearly set forth above by Craig 
in the passage above, his mask (if there is a match of the classification rule) results in "opening a 
separate connection between the service module 190 and the server 180." Therefore, persistency 
of the server-side connection is not being extended by Craig through the use of the masked 
header, but rather he opens a new separate connection. 

The other passages of Craig relied upon by the Examiner (Figure 3A and column 
11, line 45 to column 12, line 3) discuss modification of a packet header if the packet matches a 
classification rule, and is silent with respect to the "format that is unrecognizable" and 
"extending. . .the persistency" recitations of claim 20. 
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In view of at least the reasons above that the cited references do not meet all of the 
limitations of claim 20, claim 20 is not obvious. 

J. Dependent claim 21 should not be rejected under 35 U.S.C. § 103(a) on 

the basis of Craig and Peiffer 

Dependent claim 21 depends on claim 14, and by virtue of this dependency, is 
nonobvious over the cited references for the reasons set forth above with respect to claim 14. 

Dependent claim 21 is also nonobvious due to the limitations recited therein. In 
particular, dependent claim 21 recites, inter alia, the following limitations (emphasis ours): 

"wherein extending, by said network device, the persistency of the 
server-side connection includes: 

changing, by said network device, a protocol version value 
indicated in the packet received via the client-side connection to a 
different protocol version value that corresponds to maintaining a 
persistent connection." 

These limitations are not met by the cited references. In rejecting claim 21, page 7 
(section 15) of the Office Action of August 5, 2009 relies upon "the same reason" set forth to 
reject claim 11, in which column 9, lines 22-57 of Peiffer were cited in order to support the 
rejection. However, this passage of Peiffer is completely silent with respect to "changing... a 
protocol version value indicated in the packet... to a different protocol version value that 
corresponds to maintaining a persistent connection" (emphasis ours). 

Column 9, lines 47-48 of Peiffer relied upon by the Examiner talks about a "...set 
of sockets could be designated for all HTTP 1 .0 requests, with another set being designated to 
handle HTTP 1.1 requests." However, this passage is merely speaking of which type of HTTP 
requests should be designated for a particular set of sockets, and mentions nothing about 
"changing... a protocol version value indicated in the packet" to "a different protocol version 
value." 

Indeed, even the Examiner states on page 6 (section 11) of the Office Action of 
August 5, 2009 that Peiffer teaches "matching the HTTP request version with server-side socket." 
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Again, such interpretation of Peiffer has nothing to do with "changing... a protocol version value 
indicated in the packet" to "a different protocol version value" as recited in claim 21 . 

In view of at least the reasons above that the cited references do not meet all of the 
limitations of claim 21, claim 21 is not obvious. 

K. Independent claim 22 should not be rejected under 35 U.S.C. § 103(a) on 
the basis of Craig and Peiffer 

Independent claim 22 recites, inter alia, the following limitations (emphasis ours): 

"receive via said client-side connection a communication that 
signals said server-side connection to close, and 

maintain persistent, by said network device, at least the server- 
side connection in response to said communication received via said 
client-side connection." 

In rejecting claim 22 on page 8 (section 16) of the Office Action of August 5, 
2009, the Examiner uses "the same reason" to reject claim 1, in which column 17, line 57 to 
column 18, line 1 1 of Craig was cited as allegedly teaching "receiving at the network device via 
said client-side connection a communication that signals said server-side connection to close." 
As further reason(s), the Examiner asserts on page 3 (section 6) of the Office Action of August 5, 
2009 that this passage of Craig teaches that "during the close state the service module responds to 
communication received by the client in order to close connection that closing [sic] the client-side 
connection and maintaining the server-side connection." 

The Examiner's assertions that Craig teaches the recitations of claim 22 are 
traversed herein. Craig's column 17, line 57 to column 18, line 11 relied upon by the Examiner 
was previously reproduced above. In this passage, Craig clearly teaches that he closes (rather 
than "maintain persistent") his server-side connection in response to a communication, which he 
describes as "conventional closure handshakes" and/or "...responds to messages received by the 
wireless client 110" that signals the server-side connection to close. Accordingly, Craig does not 
meet the limitations of claim 22 that require, inter alia, "maintain persistent, by said network 
device, at least the server-side connection in response to said communication received via said 
client-side connection" (emphasis ours). 
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On page 4 (section 6) of the Office Action of August 5, 2009, the Examiner relies 
upon Peiffer (column 9, line 58 to column 10) as allegedly teaching "maintaining persistent... at 
least the server-side connection in response to..." However, column 9, lines 62-63 of Peiffer 
explicitly teaches that the persistent connection is maintained open "unless explicitly commanded 
to close" (emphasis ours). Therefore, Peiffer will also CLOSE (rather than "maintain persistent" 
as recited in claim 22) the server-side connection in response to "explicitly command[s]" for the 
server-side connection to close. Thus, Peiffer does not cure the deficiencies of Craig with respect 
to the recitations in claim 22 of "maintain persistent, by said network device, at least the server- 
side connection in response to said communication received via said client-side connection [that 
signals said server-side connection to close]." 

In view of the above, since all of the limitations of claim 22 are not met by the 
cited references, claim 22 is not obvious. 

L. Dependent claims 23, 24, 46, and 47 should not be rejected under 35 
U.S.C. § 103(a) on the basis of Craig and Peiffer 

Dependent claims 23, 24, 46, and 47_depend on claim 22, and by virtue of this 
dependency, are nonobvious over the cited references for the reasons set forth above with respect 
to claim 22. 

M. Dependent claim 25 should not be rejected under 35 U.S.C. § 103(a) on 
the basis of Craig and Peiffer 

Dependent claim 25 depends on claim 22, and by virtue of this dependency, is 
nonobvious over the cited references for the reasons set forth above with respect to claim 22. 

Dependent claim 25 is also nonobvious due to the limitations recited therein. In 
particular, dependent claim 25 recites, inter alia, the following limitations (emphasis ours): 

"wherein the instructions to maintain at least the server-side 
connection persistent include instructions executable by said processor to: 

modify, by said network device, header information in the 
communication that signals the server-side connection to close to a 
format unrecognizable by a server coupled to said server-side connection, 
to cause the server to ignore the modified header information." 
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These limitations are not met by the cited references. In rejecting claim 25, page 8 
(section 16) of the Office Action of August 5, 2009 relies upon "the same reason" set forth to 
reject claim 9, in which the following passages of Craig were cited to support the rejection: Figure 
3A; column 11, line 45 to column 12, line 3; column 8, lines 1-12; and column 11, lines 11-44. 
The Examiner's reliance upon Craig to reject claim 25 is erroneous. 

Column 8, lines 1-12 and column 11, lines 11-44 of Craig, which talks about a 
"mask" and classification rules, was previously quoted above. Assuming arguendo and 
hypothetically that Craig's "mask" can be interpreted as the "format unrecognizable by a server" 
recited in claim 25, Craig still does not meet the other recitations of claim 25 that require 
"maintain at least the server-side connection persistent." As clearly set forth above by Craig in 
the passage above, his mask (if there is a match of the classification rule) results in "opening a 
separate connection between the service module 190 and the server 180." Therefore, persistency 
of the server-side connection is not being maintained by Craig through the use of the masked 
header, but rather he opens a new separate connection. 

Still further, claim 25 recites "...to cause the server to ignore the modified header 
information" (emphasis ours). Craig does not ignore the header that has masked values. Rather 
than ignoring, Craig explicitly states that he "determine[s] whether the combination of fields 
match a predetermine [d] value or range of predetermined values specified by the classification 
rule." By having to determine whether the combination of fields in the header matches the 
classification rule, Craig explicitly/implicitly does not ignore the header. 

The other passages of Craig relied upon by the Examiner (Figure 3A and column 
11, line 45 to column 12, line 3) discuss modification of a packet header if the packet matches a 
classification rule, and is silent with respect to the "format unrecognizable by a server" and 
"maintain at least the server-side connection persistent" recitations of claim 25. 

In view of at least the reasons above that the cited references do not meet all of the 
limitations of claim 25, claim 25 is not obvious. 

N. Dependent claim 26 should not be rejected under 35 U.S.C. § 103(a) on 
the basis of Craig and Peiffer 
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Dependent claim 26 depends on claim 22, and by virtue of this dependency, is 
nonobvious over the cited references for the reasons set forth above with respect to claim 22. 

Dependent claim 26 is also nonobvious due to the limitations recited therein. In 
particular, dependent claim 26 recites, inter alia, the following limitations (emphasis ours): 

"wherein the instructions to maintain at least the server-side 
connection persistent include instructions executable by said processor to: 

modify, by said network device, a protocol version number 
indicated in the communication to a different protocol version number 
that corresponds to a persistent connection." 

These limitations are not met by the cited references. In rejecting claim 26, page 8 
(section 16) of the Office Action of August 5, 2009 relies upon "the same reason" set forth to 
reject claim 11, in which column 9, lines 22-57 of Peiffer were cited in order to support the 
rejection. However, this passage of Peiffer is completely silent with respect to "modify... a 
protocol version number indicated in the communication .. .to a different protocol version 
number that corresponds to a persistent connection" (emphasis ours). 

Column 9, lines 47-48 of Peiffer relied upon by the Examiner talks about a "...set 
of sockets could be designated for all HTTP 1 .0 requests, with another set being designated to 
handle HTTP 1.1 requests." However, this passage is merely speaking of which type of HTTP 
requests should be designated for a particular set of sockets, and mentions nothing about 
"modify... a protocol version number indicated in the communication... to a different protocol 
version number." 

Indeed, even the Examiner states on page 6 (section 11) of the Office Action of 
August 5, 2009 that Peiffer teaches "matching the HTTP request version with server-side socket." 
Again, such interpretation of Peiffer has nothing to do with "modify... a protocol version number 
indicated in the communication" to "a different protocol version number" as recited in claim 26. 

In view of at least the reasons above that the cited references do not meet all of the 
limitations of claim 26, claim 26 is not obvious. 
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O. Independent claim 27 should not be rejected under 35 U.S.C. § 103(a) on 
the basis of Craig and Peiffer 

Independent claim 27 recites, inter alia, a network device having (emphasis ours): 

"means for ... extending persistency of the server-side connection 
if the read content of the packet signals said server-side connection to 
close." 

In rejecting claim 27 on page 7 (section 16) of the Office Action of August 5, 
2009, the Examiner uses "the same reason" to reject claim 1, in which column 17, line 57 to 
column 18, line 1 1 of Craig was cited as allegedly teaching "receiving at the network device via 
said client-side connection a communication that signals said server-side connection to close." 
As further reason(s), the Examiner asserts on page 3 (section 6) of the Office Action of August 5, 
2009 that this passage of Craig teaches that "during the close state the service module responds to 
communication received by the client in order to close connection that closing [sic] the client-side 
connection and maintaining the server-side connection." 

The Examiner's assertions that Craig teaches the recitations of claim 27 are 
traversed herein. Craig's column 17, line 57 to column 18, line 11 relied upon by the Examiner 
was previously reproduced above. In this passage, Craig clearly teaches that he closes (rather 
than "extending persistency of) his server-side connection in response to the "conventional 
closure handshakes" and/or "...responds to messages received by the wireless client 110" that 
signals the server-side connection to close. Accordingly, Craig does not meet the limitations of 
claim 27 that require, inter alia, 'extending persistency of the server-side connection if the read 
content of the packet signals said server-side connection to close'" (emphasis ours). 

On page 4 (section 6) of the Office Action of August 5, 2009, the Examiner relies 
upon Peiffer (column 9, line 58 to column 10) as allegedly teaching "maintaining persistent... at 
least the server-side connection in response to..." However, column 9, lines 62-63 of Peiffer 
explicitly teaches that the persistent connection is maintained open "unless explicitly commanded 
to close" (emphasis ours). Therefore, Peiffer will also CLOSE (rather than "extending 
persistency of as recited in claim 27) the server-side connection in response to "explicitly 
command[s]" for the server-side connection to close. Thus, Peiffer does not cure the deficiencies 
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of Craig with respect to the recitations in claim 27 of "extending persistency of the server-side 
connection if the read content of the packet signals said server-side connection to close." 

In view of the above, since all of the limitations of claim 27 are not met by the 
cited references, claim 27 is not obvious. 

P. Dependent claim 28 should not be rejected under 35 U.S.C. § 103(a) on 

the basis of Craig and Peiffer 

Dependent claim 28 depends on claim 27, and by virtue of this dependency, is 
nonobvious over the cited references for the reasons set forth above with respect to claim 27. 

Dependent claim 28 is also nonobvious due to the limitations recited therein. In 
particular, dependent claim 28 recites, inter alia, the following limitations (emphasis ours): 

"wherein the means for extending the persistency of the server-side 
connection modifies header information in the packet to a format 
unrecognizable to a server coupled to said server-side connection to 
receive said packet." 

These limitations are not met by the cited references. In rejecting claim 28, page 8 
(section 16) of the Office Action of August 5, 2009 relies upon "the same reason" set forth to 
reject claim 9, in which the following passages of Craig were cited to support the rejection: Figure 
3A; column 11, line 45 to column 12, line 3; column 8, lines 1-12; and column 11, lines 11-44. 
The Examiner's reliance upon Craig to reject claim 28 is erroneous. 

Column 8, lines 1-12 and column 11, lines 11-44 of Craig, which talks about a 
"mask" and classification rules, was previously quoted above. Assuming arguendo and 
hypotheticatty that Craig's "mask" can be interpreted as the "format unrecognizable to a server" 
recited in claim 28, Craig still does not meet the other recitations of claim 28 that require 
"extending the persistency of the server-side connection." As clearly set forth above by Craig in 
the passage above, his mask (if there is a match of the classification rule) results in "opening a 
separate connection between the service module 190 and the server 180." Therefore, persistency 
of the server-side connection is not being extended by Craig through the use of the masked 
header, but rather he opens a new separate connection. 
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The other passages of Craig relied upon by the Examiner (Figure 3A and column 
11, line 45 to column 12, line 3) discuss modification of a packet header if the packet matches a 
classification rule, and is silent with respect to the "format unrecognizable to a server" and 
"extending the persistency" recitations of claim 28. 

In view of at least the reasons above that the cited references do not meet all of the 
limitations of claim 28, claim 28 is not obvious. 

Q. Dependent claim 29 should not be rejected under 35 U.S.C. § 103(a) on 
the basis of Craig and Peiffer 

Dependent claim 29 depends on claim 27, and by virtue of this dependency, is 
nonobvious over the cited references for the reasons set forth above with respect to claim 27. 

Dependent claim 29 is also nonobvious due to the limitations recited therein. In 
particular, dependent claim 29 recites, inter alia, the following limitations (emphasis ours): 

"wherein the means for extending the persistency of the server-side 
connection modifies header information in the packet to indicate a 
protocol version that corresponds to a persistent connection." 

These limitations are not met by the cited references. In rejecting claim 29, page 8 
(section 16) of the Office Action of August 5, 2009 relies upon "the same reason" set forth to 
reject claim 11, in which column 9, lines 22-57 of Peiffer were cited in order to support the 
rejection. However, this passage of Peiffer is completely silent with respect to "modifies header 
information in the packet to indicate a protocol version that corresponds to a persistent 
connection" (emphasis ours). 

Column 9, lines 47-48 of Peiffer relied upon by the Examiner talks about a "...set 
of sockets could be designated for all HTTP 1 .0 requests, with another set being designated to 
handle HTTP 1.1 requests." However, this passage is merely speaking of which type of HTTP 
requests should be designated for a particular set of sockets, and mentions nothing about 
"modifies header information in the packet to indicate a protocol version that corresponds to a 
persistent connection." 
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Indeed, even the Examiner states on page 6 (section 11) of the Office Action of 
August 5, 2009 that Peiffer teaches "matching the HTTP request version with server-side socket." 
Again, such interpretation of Peiffer has nothing to do with "modifies header information in the 
packet to indicate a protocol version that corresponds to a persistent connection" as recited in 
claim 29. 

In view of at least the reasons above that the cited references do not meet all of the 
limitations of claim 29, claim 29 is not obvious. 



R. Dependent claims 30 and 48-50 should not be rejected under 35 U.S.C. 

§ 103(a) on the basis of Craig and Peiffer 

Dependent claims 30 and 48-50 depend on claim 27, and by virtue of this 
dependency, are nonobvious over the cited references for the reasons set forth above with respect 
to claim 27. 



S. Dependent claim 51 should not be rejected under 35 U.S.C. § 103(a) on 

the basis of Craig, Peiffer, and Susai 

Dependent claim 51 depends on claim 27, and by virtue of this dependency, is 
nonobvious over the cited references for the reasons set forth above with respect to claim 27. 

T. Independent claim 3 1 should not be rejected under 35 U.S.C. § 103(a) on 
the basis of Craig and Peiffer 

Independent claim 31 recites, inter alia, the following limitations (emphasis ours): 

"software executable by the processor to maintain persistent at 
least the server-side connection in response to a communication received 
via said client-side connection that signals said server-side connection to 
close." 



In rejecting claim 31 on page 8 (section 16) of the Office Action of August 5, 
2009, the Examiner uses "the same reason" to reject claim 1, in which column 17, line 57 to 
column 18, line 1 1 of Craig was cited as allegedly teaching "receiving at the network device via 
said client-side connection a communication that signals said server-side connection to close." 
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As further reason(s), the Examiner asserts on page 3 (section 6) of the Office Action of August 5, 
2009 that this passage of Craig teaches that "during the close state the service module responds to 
communication received by the client in order to close connection that closing [sic] the client-side 
connection and maintaining the server-side connection." 

The Examiner's assertions that Craig teaches the recitations of claim 31 are 
traversed herein. Craig's column 17, line 57 to column 18, line 11 relied upon by the Examiner 
was previously reproduced above. In this passage, Craig clearly teaches that he closes (rather 
than "maintain persistent") his server-side connection in response to a communication, which he 
describes as "conventional closure handshakes" and/or "...responds to messages received by the 
wireless client 110" that signals the server-side connection to close. Accordingly, Craig does not 
meet the limitations of claim 31 that require, inter alia, "maintain persistent at least the server- 
side connection in response to a communication received via said client-side connection that 
signals said server-side connection to close" (emphasis ours). 

On page 4 (section 6) of the Office Action of August 5, 2009, the Examiner relies 
upon Peiffer (column 9, line 58 to column 10) as allegedly teaching "maintaining persistent... at 
least the server-side connection in response to..." However, column 9, lines 62-63 of Peiffer 
explicitly teaches that the persistent connection is maintained open "unless explicitly commanded 
to close" (emphasis ours). Therefore, Peiffer will also CLOSE (rather than "maintain persistent" 
as recited in claim 31) the server-side connection in response to "explicitly command[s]" for the 
server-side connection to close. Thus, Peiffer does not cure the deficiencies of Craig with respect 
to the recitations in claim 3 1 of "maintain persistent at least the server-side connection in response 
to a communication received via said client-side connection that signals said server-side 
connection to close." 

In view of the above, since all of the limitations of claim 3 1 are not met by the 
cited references, claim 31 is not obvious. 

U. Dependent claim 32 should not be rejected under 35 U.S.C. § 103(a) on 
the basis of Craig and Peiffer 

Dependent claim 32 depends on claim 31, and by virtue of this dependency, is 
nonobvious over the cited references for the reasons set forth above with respect to claim 3 1 . 
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Dependent claim 32 is also nonobvious due to the limitations recited therein. In 
particular, dependent claim 32 recites, inter alia, the following limitations (emphasis ours): 

"wherein the software executable by said processor of said network device 
to maintain the server-side connection persistent includes code to modify a 
format of header information in the communication received via the 
client-side connection from a format that signals said server-side 
connection to close to a format that is unrecognizable by a server 
coupled to said server-side connection, to cause the server to ignore the 
header information." 



These limitations are not met by the cited references. In rejecting claim 32, page 8 
(section 16) of the Office Action of August 5, 2009 relies upon "the same reason" set forth to 
reject claim 9, in which the following passages of Craig were cited to support the rejection: Figure 
3 A; column 11, line 45 to column 12, line 3; column 8, lines 1-12; and column 11, lines 11-44. 
The Examiner's reliance upon Craig to reject claim 32 is erroneous. 

Column 8, lines 1-12 and column 11, lines 11-44 of Craig, which talks about a 
"mask" and classification rules, was previously quoted above. Assuming arguendo and 
hypothetically that Craig's "mask" can be interpreted as the "format that is unrecognizable by a 
server" recited in claim 32, Craig still does not meet the other recitations of claim 32 that require 
"maintain the server-side connection persistent." As clearly set forth above by Craig in the 
passage above, his mask (if there is a match of the classification rule) results in "opening a 
separate connection between the service module 190 and the server 180." Therefore, persistency 
of the server-side connection is not being maintained by Craig through the use of the masked 
header, but rather he opens a new separate connection. 

Still further, claim 32 recites "...to cause the server to ignore the header 
information" (emphasis ours). Craig does not ignore the header that has masked values. Rather 
than ignoring, Craig explicitly states that he "determine[s] whether the combination of fields 
match a predetermine [d] value or range of predetermined values specified by the classification 
rule." By having to determine whether the combination of fields in the header matches the 
classification rule, Craig explicitly/implicitly does not ignore the header. 
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The other passages of Craig relied upon by the Examiner (Figure 3A and column 
11, line 45 to column 12, line 3) discuss modification of a packet header if the packet matches a 
classification rule, and is silent with respect to the "format that is unrecognizable by a server" and 
"maintain the server-side connection persistent" and "ignore" recitations of claim 32. 

In view of at least the reasons above that the cited references do not meet all of the 
limitations of claim 32, claim 32 is not obvious. 

V. Dependent claim 33 should not be rejected under 35 U.S.C. § 103(a) on 
the basis of Craig and Peiffer 

Dependent claim 33 depends on claim 31, and by virtue of this dependency, is 
nonobvious over the cited references for the reasons set forth above with respect to claim 3 1 . 

Dependent claim 33 is also nonobvious due to the limitations recited therein. In 
particular, dependent claim 33 recites, inter alia, the following limitations (emphasis ours): 

"wherein the software executable by said processor of said network device 
to maintain the server-side connection persistent includes code to modify a 
HTTP protocol version value indicated in the communication received 
via the client-side connection to a HTTP protocol version value that is 
associated with a persistent connection." 

These limitations are not met by the cited references. In rejecting claim 33, page 8 
(section 16) of the Office Action of August 5, 2009 relies upon "the same reason" set forth to 
reject claim 11, in which column 9, lines 22-57 of Peiffer were cited in order to support the 
rejection. However, this passage of Peiffer is completely silent with respect to "modify a HTTP 
protocol version value indicated in the communication received via the client-side connection to 
a HTTP protocol version value that is associated with a persistent connection" (emphasis ours). 

Column 9, lines 47-48 of Peiffer relied upon by the Examiner talks about a ". . .set 
of sockets could be designated for all HTTP 1 .0 requests, with another set being designated to 
handle HTTP 1.1 requests." However, this passage is merely speaking of which type of HTTP 
requests should be designated for a particular set of sockets, and mentions nothing about "modify 
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a HTTP protocol version value... to a HTTP protocol version value that is associated with a 
persistent connection." 

Indeed, even the Examiner states on page 6 (section 11) of the Office Action of 
August 5, 2009 that Peiffer teaches "matching the HTTP request version with server-side socket." 
Again, such interpretation of Peiffer has nothing to do with "modify a HTTP protocol version 
value... to a HTTP protocol version value that is associated with a persistent connection" as 
recited in claim 33. 

In view of at least the reasons above that the cited references do not meet all of the 
limitations of claim 33, claim 33 is not obvious. 

W. Dependent claims 34, 36, and 52 should not be rejected under 35 U.S.C. 
§ 103(a) on the basis of Craig and Peiffer 

Dependent claims 34, 36, and 52 depend on claim 31, and by virtue of this 
dependency, are nonobvious over the cited references for the reasons set forth above with respect 
to claim 3 1 . 

X. Dependent claim 35 should not be rejected under 35 U.S.C. § 103(a) on 

the basis of Craig, Peiffer, and Susai 

Dependent claim 35 depends on claim 31, and by virtue of this dependency, is 
nonobvious over the cited references for the reasons set forth above with respect to claim 3 1 . 
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In view of the arguments as set forth above, the Examiner's rejections of the 
claims should be withdrawn. 



Respectfully submitted, 
Schwabe, Williamson & Wyatt 

/Dennis M. de Guzman/ 



Dennis M. de Guzman 
Registration No. 41,702 

DMD:jah 

1420 Fifth Avenue, Suite 3400 
Seattle, Washington 98101 
Phone: (206)407-1574 
Fax: (206) 292-0460 
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VIII. CLAIMS APPENDIX 

In accordance with 37 CFR 41.37(c)(l)(viii), provided herewith is an appendix 
containing a copy of the "claims involved in the appeal." It is noted that canceled claims 37-42 
are not "involved in the appeal", and therefore 37 CFR 41.37(c)(l)(viii) does not require a copy 
of these canceled claims to be included below: 

1 . A method, comprising: 

at a network device, providing a hypertext transfer protocol (HTTP) client-side 
connection and a HTTP server-side connection; 

receiving at said network device via said client-side connection a communication 
that signals said server-side connection to close; and 

maintaining persistent, by said network device, at least the server-side connection 
in response to said communication received via said client-side connection. 

2. The method of claim 1, further comprising closing the client-side 
connection while the server-side connection is maintained persistent. 

3. The method of claim 1 wherein maintaining persistent at least the server- 
side connection in response to said communication received via said client-side connection 
includes: 

de-linking, by said network device, the server-side connection from the client-side 
connection in response to a RESET packet received by said network device via said client-side 
connection. 

4. The method of claim 1 wherein maintaining persistent at least the server- 
side connection in response to said communication received via said client-side connection 
includes: 
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de-linking, by said network device, the server-side connection from the client-side 
connection in response to a FIN packet received by said network device via said client-side 
connection. 

5. The method of claim 1, further comprising said network device closing 
both the client-side and server-side connections in response to a FIN packet received by said 
network device via said server-side connection. 

6. The method of claim 1 wherein maintaining persistent at least the server- 
side connection in response to said communication received via said client-side connection 
includes: 

identifying, by said network device, a Connection: Close header in the 
communication received via the client-side connection; and 

replacing, by said network device, the Connection: Close header in the 
communication with a Connection: Keep- Alive header. 

7. The method of claim 6, further comprising said network device performing 
at least one of increasing a total length of a packet having the Connection: Close header, 
fragmenting the packet having the Connection: Close header, and recalculating a checksum of the 
packet. 

8. The method of claim 1 wherein maintaining persistent at least the server- 
side connection in response to said communication received via said client-side connection 
includes: 

inserting, by said network device, a Connection: Keep-Alive header in the 
communication if the communication does not contain any header information indicative of 
whether to close the HTTP connection. 
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9. The method of claim 1 wherein maintaining persistent at least the server- 
side connection in response to said communication received via said client-side connection 
includes: 

modifying, by said network device, a header in the communication from a format 
that signals the server-side connection to close to a format that is unrecognizable by a server 
coupled to said server-side connection, to cause the server to ignore the modified header. 

10. The method of claim 9 wherein modifying the header in the request to the 
form that is unrecognizable to the server includes at least one of modifying a name of the header 
and modifying a value of the header. 

1 1 . The method of claim 1 wherein maintaining persistent at least the server- 
side connection in response to said communication received via said client-side connection 
includes: 

changing, by said network device, a HTTP version value indicated in the 
communication to another HTTP version value that is recognizable by a server, coupled to said 
server-side connection, as being associated with a persistent connection. 

12. The method of claim 11, further comprising adjusting a checksum based on 
a difference between the HTTP version values. 

13. The method of claim 1 wherein the communication includes a header 
having a proxy format. 

14. A method, comprising: 

establishing at a network device a client-side connection and a server-side 

connection; 

reading, by said network device, content of a packet received via the client-side 
connection; and 
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extending, by said network device, persistency of the server-side connection if the 
read content of the packet signals said server-side connection to close. 

15. The method of claim 14 wherein establishing the client-side and server-side 
connections include establishing these connections as part of a hypertext transfer protocol (HTTP) 
connection. 

16. The method of claim 14 wherein extending, by said network device, the 
persistency of the server-side connection includes: 

de-linking, by said network device, the server-side connection from the client-side 
connection, if the read content indicates that the packet is a RESET packet received via the client- 
side connection. 

17. The method of claim 14 wherein extending, by said network device, the 
persistency of the server-side connection includes: 

de-linking, by said network device, the server-side connection from the client-side 
connection, if the read content indicates that the packet is a FIN packet received via the client-side 
connection. 

18. The method of claim 14 wherein extending, by said network device, the 
persistency of the server-side connection includes: 

identifying, by said network device, header information of the packet received via 
the client-side connection that signals the server-side connection to close; and 

replacing, by said network device, the identified header information with new 
header information that maintains the server-side connection persistent. 

19. The method of claim 14 wherein extending, by said network device, the 
persistency of the server- side connection includes: 
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determining, by said network device, that header information of the packet 
received via the client-side connection does not include any information that signals the server- 
side connection to close; and 

applying, by said network device, header information in the packet that maintains 
the server-side connection persistent. 

20. The method of claim 14 wherein extending, by said network device, the 
persistency of the server-side connection includes: 

modifying, by said network device, header information in the packet received via 
the client-side connection from a format that signals said server-side connection to close to a 
format that is unrecognizable by a server that is to receive the packet via the server-side 
connection. 

21. The method of claim 14 wherein extending, by said network device, the 
persistency of the server-side connection includes: 

changing, by said network device, a protocol version value indicated in the packet 
received via the client-side connection to a different protocol version value that corresponds to 
maintaining a persistent connection. 

22. An article of manufacture, comprising: 

a storage medium having instructions stored thereon that are executable by a 
processor of a network device to: 

provide at said network device a hypertext transfer protocol (HTTP) client-side 
connection and a HTTP server-side connection; 

receive via said client-side connection a communication that signals said server- 
side connection to close; and 

maintain persistent, by said network device, at least the server-side connection in 
response to said communication received via said client-side connection. 
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23. The article of manufacture of claim 22 wherein the instructions to maintain 
at least the server-side connection persistent include instructions executable by said processor to: 

de-link, by said network device, the server-side connection from the client-side 
connection in response to a RESET packet received via the client-side connection. 

24. The article of manufacture of claim 22 wherein the instructions to maintain 
at least the server-side connection persistent include instructions executable by said processor to: 

change, by said network device, header information in the communication received 
via the client-side connection to new header information corresponding to a persistent connection. 

25. The article of manufacture of claim 22 wherein the instructions to maintain 
at least the server-side connection persistent include instructions executable by said processor to: 

modify, by said network device, header information in the communication that 
signals the server-side connection to close to a format unrecognizable by a server coupled to said 
server-side connection, to cause the server to ignore the modified header information. 

26. The article of manufacture of claim 22 wherein the instructions to maintain 
at least the server-side connection persistent include instructions executable by said processor to: 

modify, by said network device, a protocol version number indicated in the 
communication to a different protocol version number that corresponds to a persistent connection. 

27. An apparatus, comprising: 

a network device adapted to be communicatively coupled between a client terminal 
and a server, the network device having: 

communication terminal means for establishing a client-side connection 
and a server-side connection; and 

means for reading content of a packet received via the client-side 
connection, and for extending persistency of the server-side connection if the read content 
of the packet signals said server-side connection to close. 
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28. The apparatus of claim 27 wherein the means for extending the persistency 
of the server-side connection modifies header information in the packet to a format 
unrecognizable to a server coupled to said server-side connection to receive said packet. 

29. The apparatus of claim 27 wherein the means for extending the persistency 
of the server-side connection modifies header information in the packet to indicate a protocol 
version that corresponds to a persistent connection. 

30. The apparatus of claim 27 wherein the means for extending the persistency 
of the server-side connection de-links the server-side connection from the client-side connection 
in response to RESET content in the packet received via the client side connection. 

31. An apparatus, comprising: 
a network device having: 

first and second communication terminals, the first terminal being 
associated with a hypertext transfer protocol (HTTP) client-side connection and the 
second terminal being associated with a HTTP server-side connection; 

a processor coupled to the first and second communication terminals; and 
software executable by the processor to maintain persistent at least the 
server-side connection in response to a communication received via said client-side 
connection that signals said server-side connection to close. 

32. The apparatus of claim 31 wherein the software executable by said 
processor of said network device to maintain the server-side connection persistent includes code 
to modify a format of header information in the communication received via the client-side 
connection from a format that signals said server-side connection to close to a format that is 
unrecognizable by a server coupled to said server-side connection, to cause the server to ignore 
the header information. 
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33. The apparatus of claim 31 wherein the software executable by said 
processor of said network device to maintain the server-side connection persistent includes code 
to modify a HTTP protocol version value indicated in the communication received via the client- 
side connection to a HTTP protocol version value that is associated with a persistent connection. 

34. The apparatus of claim 31 wherein the software executable by said 
processor of said network device to maintain the server-side connection persistent includes code 
to de-link the server-side connection from the client-side connection in response to said 
communication, containing a RESET, received via said client-side connection. 

35. The apparatus of claim 31 wherein the software executable by said 
processor of said network device to maintain the server-side connection persistent includes code 
to modify a Connection: Close header in the communication to Connection: Keep-Alive header. 

36. The apparatus of claim 31 wherein the software is also executable by said 
processor of said network device to close the server-side connection in response to at least one of 
a RESET and FIN received via the server-side connection. 

43. The method of claim 1 wherein said network device includes a switch. 

44. The method of claim 11 wherein changing the HTTP version value to 
another HTTP version value includes changing, by said network device, from HTTP version 1.0 
indicated in said request to HTTP version 1.1. 

45. The method of claim 14 wherein said network device includes a switch. 

46. The article of manufacture of claim 22 wherein said network device 
includes a switch. 
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47. The article of manufacture of claim 22 wherein the instructions to maintain 
at least the server-side connection persistent, in response to said communication received via said 
client-side connection, include instructions executable by said processor to: 

de-link, by said network device, the server-side connection from the client-side 
connection in response to a FIN packet received via the client-side connection. 

48. The apparatus of claim 27 wherein said network device includes a switch. 

49. The apparatus of claim 27 wherein the means for extending the persistency 
of the server-side connection, if the read content of the packet signals said server-side connection 
to close, maintains persistency by de-linking the server-side connection from the client-side 
connection in response to FIN content in the packet received via the client side connection. 

50. The apparatus of claim 27 wherein the means for extending the persistency 
of the server-side connection, if the read content of the packet signals said server-side connection 
to close, maintains persistency by de-linking the server-side connection from the client-side 
connection in response to RESET content in the packet received via the client side connection. 

5 1 . The apparatus of claim 27 wherein the means for extending the persistency 
of the server-side connection, if the read content of the packet signals said server-side connection 
to close, maintains persistency by replacing a Connection: Close header of the packet with a 
Connection: Keep-Alive header. 

52. The apparatus of claim 31 wherein the software executable by said 
processor of said network device to maintain the server-side connection persistent, in response to 
said communication received via said client-side connection that signals said server-side 
connection to close, includes code to de-link the server-side connection from the client-side 
connection in response to said communication, containing a FIN, received via said client-side 
connection. 



38 



EVIDENCE APPENDIX 
None. 



X. RELATED PROCEEDINGS APPENDIX 
None. 
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